1. Field of the Invention
The present invention generally relates to distributed computing. More particularly, the present invention relates to a system, method and computer program for developing and monitoring distributed applications, integrating component programs, integrating enterprise applications and change management.
2. Description of the Related Art
Traditionally, enterprises have employed monolithic computers for performing their computational tasks; these computers had applications that contained the logic for solving different kinds of computational tasks. Such applications, now often referred to as legacy applications, were structured either as a single large program or were split into separate programs (also called component programs) that worked together to perform the assigned task. These applications were usually created for specific hardware and could work only on this hardware.
The advent of Personal Computers (PCs) and the emergence of networking technologies made it possible to connect the monolithic computers to many PCs through a network. Here, the monolithic computer acted as a central server; it had enormous processing power, performed complex computational tasks, and usually provided various results to the PCs. The PCs, in turn, acted as clients and were usually distributed within an organization, an enterprise, a Local Area Network (LAN) or a Wide Area Network (WAN). Various human professionals would then interact with the central server using these PCs. Hence, all the processing was done at the central server, and the PCs—which were at times as simple as screens and keyboards—only performed the role of requesters. This kind of a computing model came to be known as the “client-server model.”
As network bandwidth increased and as the processing power and other resources of PCs increased, it quickly became possible for the applications (that were hitherto confined only to a central server) to be assigned to the individual PCs. When such individual applications were deployed on a plurality of networked PCs, a lot of integration issues arose, which were mainly due to the heterogeneous environment wherein such applications were deployed. Typically, such applications were, and in most cases even to this day are, spread across disparate hardware and software systems with different architectures, platforms, communication protocols and languages. This was owing to the fact that most enterprises had created their applications based on the technology of the day, without realizing how these disparate systems would later share information and interoperate. The integration of such applications (deployed across disparate platforms) is now a main concern of most enterprises and organizations.
The problems of integrating applications within an enterprise are now addressed by Enterprise Application Integration (EAI) platforms. EAI platforms provide the wherewithal for the integration of two or more disparate applications operating within an enterprise. EAI platforms have generally been used for the integration of Customer Relations Management (CRM), Supply Chain Management (SCM), Enterprise Resource Planning (ERP) and many other applications of an enterprise. Many companies like Tibco of Palo Alto, Calif., USA; Vitria of San Jose, Calif., USA; WebMethods of Fairfax, Va., USA; and IBM of Armonk, N.Y., USA, provide various kinds of EAI platforms.
The problem of integration has been further exacerbated with the emergence of electronic business (often called e-business). With the emergence of the Internet, and with advances in wired as well as wireless communications, there has been a revolutionary change in business dynamics, and many operational boundaries between enterprises have virtually become non-existent. Further, the emergence of e-business has facilitated business collaborations wherein enterprises exchange real-time product, services and market information with their partners, manufacturers, suppliers, transporters, and customers. Such collaborations place high interoperability and integration needs on most enterprises and it is vital that they integrate their systems with those of others. Some problems of integrating applications across multiple enterprises are being handled today by Business-to-Business (B2B) platforms. Many companies like Plexus of San Jose, Calif., USA; Icomexpress of Nashua, N.H., USA; Ariba of Mountain View, Calif., USA; and IBM of Armonk, N.Y., USA, provide such B2B platforms.
Although the above-mentioned EAI and B2B platforms have proved advantageous in overcoming some integration problems, they suffer from certain shortcomings. These platforms typically specify the workflow and data routes within the application code itself while integrating the different applications. This results in an inflexible integrated application where any modification in the workflow or data routes entails changing the application code itself. Indeed, this is a very tedious process. Further, since data routing is embedded within the application code, any network failure may result in the halting of the integrated application, which in turn, may require re-routing the data as well as recompilation and re-launching of the integrated application. Therefore, EAI and B2B platforms provided by such companies tend to be very rigid and involve a lot of custom programming.
There are many other platforms that provide for integration of applications where the complete workflow and the routing tables are stored in a central server or a central computer. In this scenario, all applications are required to send their data and information to this central server and it is the central server that uses stored routing tables to route this information to other applications, nodes or computers. Thus, there is no direct routing between the applications. Further, any changes to routes or any addition of new routes would require modifications at the centralized server. In addition, all data exchanged between applications needs to go through the central server, thereby, causing this server to become a single point of failure. This type of topological restriction is inefficient and inflexible, and it forces obvious bottlenecks into the distributed system. Clearly, these problems are likely to exacerbate while trying to integrate applications in an enterprise or across several enterprises.
It may be noted that the above problems would also exist in case a large and complex application is broken down into component programs and distributed across multiple computers connected over a network. The problems faced would now apply to the task of integrating the distributed component programs so as to make their conglomeration work as one application, and perform a computing task in a distributed manner. Such a form of computing is known as distributed computing, and even though this field shares a lot of problems with the field of application integration, the two are not to be considered the same. In general, the solutions/platforms available for application integration do not apply for distributed computing, although the concepts/ideas of the solution might find their use in distributed computing and vice versa.
Many companies like United Devices of Austin, Tex., USA and Ubero Inc. build software platforms that attempt to solve complex problems using distributed computing. These companies do not build platforms that help developers create new distributed applications easily; instead, they provide for an agent based platform that efficiently utilizes the unused power of various computers, servers and PCs in a network. Hence, in addition to all the problems mentioned in previous paragraphs, the developer also has to worry about the routing of information between the component programs, monitoring the component programs, handling additions and replacements of the component programs, and other related issues with the software platforms provided by United Devices and Ubero, Inc.
Software infrastructures also exist that aid developers in creating distributed applications; indeed, Aramira Inc. of San Jose, Calif., USA, provides such an infrastructure, that is called Jumping Beans. The distributed applications created using this infrastructure physically “jump” from one machine to another while the application is running. In other words, while the application is running on one computer, it picks itself up and physically moves to another computer on the network and then resumes execution. The software infrastructure provides central control of the distributed application(s) and requires client software to be installed on the participating computers for facilitating receipt of the distributed application and also for monitoring and security purposes. However, the Jumping Beans infrastructure has certain inherent shortcomings. Once an application has been launched, there is no control over the routing information. Therefore, after launching the distributed application it is not possible to change the order in which the application shall jump across various computers. Indeed, if the order has to be changed, then the application would have to be stopped and the routes have to be changed before re-launching it. Moreover, the monitoring and controlling of the distributed applications have to be done using a central server.
U.S. Pat. Nos. 5.625,823 and 6,144,984, have been issued to Eric DeBenedictis and Steve Johnson. These patents are titled “A method and apparatus for Controlling Connected Computers without programming”. These patents outline a process for creating, maintaining and executing network applications.
In the process outlined by these patents, applications are created using tasks as the building blocks. These tasks are created using a Graphical User Interface (GUI) by typing in the code of a program that is to be executed. The IP address or the name of the computer on which the program is to be executed is also typed in this GUI. This results in the creation of a task, represented by an icon, which is then stored in a palette. A distributed application is then created by dragging icons from this palette and dropping them on a “screen.” The data routes between the icons are then created by drawing “directed line segments” (also called “arcs”) among them. Once the routes are drawn out, the application can be executed. Upon execution, the computer to which the first task is assigned receives the entire application and executes the task. The output that results from the execution of this first task along with the entire application is carried to the computer to which the second task is assigned; the directed line segment from the first task (or icon) points to the second task (or the second icon). This process is continued until the whole application is executed. Thus, the process of deploying the application as tasks is combined with the process of executing the tasks.
The above-mentioned system has certain inherent shortcomings. First, this system is wholly dependant on the GUI for composing a distributed application since linking icons in the GUI is the only way to develop the application. Second, as the code has to be typed in the GUI to create a task, no pre-built or off-the-shelf application can be easily used in this system. Third, the system necessarily requires each task to be created and launched from within its environment and these tasks cannot be re-used by similar applications. Fourth, it is difficult to change the routes or tasks at run time, since any change would entail re-compiling or re-transmitting the entire application. Fifth, as the name of computer (or its IP address) is embedded into the task itself, these tasks have to be aware of the underlying communication fabric that complicates the creation and modification of the tasks. Sixth, the system uses the types of tasks as a failsafe, which results in a tightly coupled system. Finally, the process of transferring tasks to execute the application from one node to another at run time consumes a lot of network bandwidth. Because of the aforementioned shortcomings, this system does not allow pre-built component programs or applications to be easily integrated into the system.
The preceding discussion reveals that the abovementioned system combines the processes of deployment, computation and communication within the tasks, and thus makes the resulting distributed application very rigid. Moreover, any change in the connections (or “routes” between tasks) requires the application to be stopped followed by manual changes using the GUI. Specifically, the above-mentioned system is unable to support applications with a dynamic workflow.
It may thus be noted that although work has been done in the area of developing distributed applications; the prior art does not address the problem of developing distributed application easily. Prior art also does not provide for dynamically changing the distributed application to meet many real world requirements.
Therefore, in light of the abovementioned drawbacks, there is a need for a system, method and computer program product for developing distributed applications easily, that would provide for separation of tasks of deployment, computation, communication and monitoring in terms of time, space and people involved, thereby minimizing the impact of change in one stage on the other and allowing for dynamic changes to the application, as desired. There is also a need for a system, method and computer program product that addresses integration of applications both within and across enterprises.